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(57) Abstract: Different data streams (DS300, DS310, 
DS320, DS330) undergo different data compression methods 
before being multiplexed in order to multiplex a plurality 
of data packets of several data streams (DS300, DS310, 
DS320, DS330) in an allocated RLC unit (radio link conu-ol) 
(RLC600) within the packet data convergence protocol 
(PDCP) of a UMTS radiocommunication system. At least 
one individual identification of the data stream (DS400*, 
DS410*, DS330) entering the multiplexing unit (MUPl) 
is made between the corresponding data compression unit 
(CA400, CA410) and the multiplexing unit (MUPl). 

(57) Zusammenfassung: Zum Mulliplexen einer 
Vielzahl von Date npake ten mehrerer Datenstrome 
(DS300, DS310, DS320, DS330) auf eine zugeordnete 
RLC-Einheit (radio link control) (RLC600) innerhalb 
des PDCP-Protokolls (packet data convergence protocol) 
eines UMTS-Funkkommunikationsystems werden die 
verschiedenen Datenstrome (DS300, DS310, DS320, 
DS330) vor ihrem Multiplexen mit unterschiedlichen 
Datenkompressionsverfahren beaufschlagt. Dabei wird 
zwischen der jeweiligen Datenkompressionseinheit (CA400, 
CA410) und der Multiplexereinheit (MUPl) jeweils 
mindestens eine individuelle Kennzeichnung des jeweihg in 
die Multiplexereinheit (MUPl) einlaufenden Datenstroms 
(DS400*, DS410*, DS330) vorgenommen wird. 
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1 

Beschreibung 

Verfahren zvm Multiplexer! einer Vielzahl von Datenpaketen 
mehrerer Datenstrome innerhalb des PDCP-Protokolls eines 
5 UMTS -Funkkommunikationsys terns 

Die Erfindung beschaftigt sich mit dem Problem, in einem 
Funkkommunikat ions system, das insbesondere nach dem UMTS- 
Standard ausgebildet sein kann, den Austausch von Datenstro- 
10 men zwischen dessen Teilnehmergeraten, insbesondere Mobil- 

funkgeraten, und Funknetzwerkeinheiten, insbesondere Funkkon- 
trolleinheiten zu . verbessern. 

Dies wird durch die Merkmale des Anspruchs 1 und/oder durch 
die Merkmale des Anspruchs 5 gelost, 

15 

Durch dieses Multiplexen einer Vielzahl von Datenpaketen meh- 
rerer Datenstrome innerhalb des PDCP-Protokolls eines UMTS- 
Funkkommunikations systems nach einer der beiden oder zugleich 
nach beiden Losungsvarianten wird der Datenaustausch zwischen 
20 dessen Teilnehmergeraten und Funkkontrolleinheiten effizien- 
ter. 

Die Erfindung betrif ft weiterhin ein UMTS- 

Funkkommunikationssystem, in dem der Austausch von Datenstro- 
25 men zwischen dessen Teilnehmergeraten/ insbesondere Mobil- 
funkgeraten, und Netzwerkeinheiten, insbesondere Funkkon- 
trolleinheiten, nach mindestens einem der erf indungsgemaJien 
Multiplexverf ahren vorgenommen wird. 

30 

Sonstige Weiterbildungen der -Erfindung sind in den Unteran- 
sprtichen wiedergegeben . 

Die Erfindung und ihre Weiterbildungen werden nachfolgend an- 
35 hand von Zeichnungen naher erlautert. 
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Es zeigen: 

Figur 1 in scheitiatischer Darstellung den Aufbau eines Funk- 
kommunikationssystems, vorzugsweise Mobil funknet- 
5 zes, das insbesondere nach dem UMTS- Standard auf- 

gebaut ist und nach dessen PDCP-Protokoll (packet 
data convergence protocol) arbeitet, 

Figur 2 in scheitiatischer Darstellung die Protokollschichten 
10 zwischen einem Teilnehmergerat, insbesondere einer 

Mobilfunkstation, einer Basisstation und einer 
Funkkontolleinheit (radio network controller) des 
Funkkommunikationssystems nach Figur 1, und 

15 Figur 3 in schematischer Darstellung zwei erf indungsgemaiie 
Multiplexverf ahren ftir eine Vielzahl von Datenpake- 
ten mehrerer Datenstrome, wie sie im jeweiligen 
Teilnehmergerat und der jeweiligen Funkkontrollein- 
heit einzeln oder zusammen durchgeftihrt werden. 

20 

Elemente mit gleicher Funktion und Wirkungsweise sind in den 
Figuren 1 mit 3 jeweils mit denselben Bezugszeichen versehen. 

In vielen Dateniibertragungssystemen werden Daten paketweise 
25" erzeugt (bspw. Web-Browsing) und paket^orientiert ubertragen. 
Dazu werde die von einer oder mehreren Applikationen (Pro- 
grammen) erzeugten Paketdaten in verschiedenen, nacheinander 
durchlaufenen Protokollen fur die Dbertragung in paketorien- 
tierten Netzen manipuliert. 

30 

Fiir eine f ehlerminimierte, paketorientierte Dateniibertragung 
werden beispielsweise haufig die Protokolle TCP (RFC 793, 
Transmission Control Protocol (TCP), IETF September 1981, 
http://www.ietf.org/rfc.html) und IP (RFC 791, Internet Pro- 
35 tocol (IP), IETF September 1981, 

http : //www. ietf , org/rf c . html ) verwendet : 
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Dabei werden die von einer Applikation in einer ersten Ein- 
heit des Datenubertragungssystems (Sender) erzeugten Paketda- 
ten zusammen mit einer Angabe uber das Ziel der Daten zu- 
5 nachst dem TCP Protokoll iiu Sender iibergeben- Den Paketdaten 
werden vom TCP Protokoll Kontrolldaten (TCP header) vorrange- 
stellt, die unter anderem Inf ormationen iiber die Quell- 
Applikation, von der die Daten stammen, (Source Port) , die 
Ziel-Applikation, fur die die Daten bestimmt sind, (Destina- 
10 tion Port) und Daten zur Fehlerbehebung und -erkennung ent- 
halten, Der TCP header ist in (RFC 793, Transmission Control 
Protocol (TCP), IETF September 1981, 

http://vsnArw.ietf.org/rfc.html (p. 14)) beschrieben. Er ist min- 
destensieo bit (5 Oktetts) lang und bildet zusammen mit den 

15 Paketdaten das TCP Paket . 

Das TCP Paket wird dann an das IP Protokoll im Sender iiberge- 
ben, welches dem TCP Paket IP Kontrolldaten (IP header) vor- 
ranstellt, die unter anderem Inf ormationen uber die Sender- 
(Source IP-Address) und Empf anger-Einheit (Destination IP- 

20 Address), die geforderte Ubertragungsqualitat und das zuvor 

genutzte Protokoll (in diesem Beispiel TCP) enthalten. Der IP 
header ist in (RFC 791, Internet Protocol (IP), IETF Septem- 
ber 1981, http://www.ietf.org/rfc.html (p. 10)) beschrieben. 
Er ist mindestens 160 bit (5 Oktetts) lang und bildet zusam- 

25 men mit dem TCP Paket das IP Paket. 

Das so zusammengestellte IP Paket, bestehend aus Paketdaten, 
TCP header und IP header, wird in Abhangigkeit von der in dem 
Datenubertragungssystem genutzten Obertragungstechnik eventu- 

30 ell Uber mehrere Systemeinheiten zu der in der Destination 

IP-Address des IP headers adressierten Ziel-Einheit (Empfan- 
ger) ubertragen. Im Empf anger entfernt dann zunachst das IP 
Protokoll den IP header von dem IP Paket und tibergibt das so 
erhaltene TCP Paket dem TCP Protokoll. Dieses entfernt den 

35 TCP header und tibergibt die so erhaltenen Paketdaten der 

durch den Destination Port im TCP header gekennzeichneten Ap- 
plikation. 
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Beide hier erwahnten Protokolle (TCP und IP) konnen die Da- 
tenpakete eventuell auch auf andere Weise manipulieren (bei- 
spielsweise durch Segmentierung aus einem groflen Paket mehre- 
5 re kleinere generieren) , jedoch 1st hier insbesondere nur das 
Prinzip der TCP / IP header relevant. 

Fur Echtzeit-Datentibertragungen werden haufig insbesondere 
die Protokolle RTP (RFC, Real Time Protocol (RTP) , IETF) , UDP 
10 (RFC 758, User Datagram Protocol (UDP), August 1980, 

http://www.ietf.org/rfc.html), und IP (RFC 7 91, Internet Pro- 
tocol (IP), IETF September 1981, 

http://www.ietf.org/rfc.html) verwendet. Das Prinzip der Da- 
teniibertragung ist dabei dem oben beschriebenen sehr ahnlich: 

15 

Im Sender werden Paketdaten generiert, die zunachst dem RTP 
Protokoll im Sender ubergeben werden. RTP stellt den Daten 
dann den RTP header voran und bildet mit den eigentlichen Da- 
ten das RTP Paket. Diesem wird dann vom UDP Protokoll der UDP 
20 header vorangestellt und das so erhaltene UDP Paket wird vom 
IP Protokoll ebenso wie ein TCP Paket ubertragen. Im Empf an- 
ger werden dann alle Kontrolldaten wieder entfernt, urn die 
Paketdaten zu erhalten und sie an die das RTP Protokoll nut- 
zende Applikation zu ubergeben. 

25 

Das IP Protokoll stellt ein sehr haufig in Paketdatennetzen 
benutztes Protokoll der Netzwerkschicht dar, aber auch andere 
Protokolle konnen Verwendung finden (bspw. X.25 (RFC, X.25, 
IETF) . Der allgemeine, in UMTS benutzte Begrif f ist das soge- 
30 nannte Paketdatenprotokott (PDP) , die zum Routen der Paketda- 
ten verwendete Adresse, in obigem Beispiel also die IP 
Address, wird insbesondere PDP Address genannt. 

Besteht das Datenubertragungssystem, in dem die Paketdaten 
35 ubertragen werden sollen, ganz oder teilweise aus einem Mo- 
bilfunksystem, insbesondere UMTS- Funkkommunikationssystem, 
so ist es vorteilhaft, die wie oben beschrieben erzeugten Pa- 
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ketdaten (bspw. IP Pakete) von den verschiedenen UMTS Proto- 
kollen fur eine effiziente Obertragung durch das Mobilfunk- 
system auf zubereiten. Insbesondere ist es zweckmaliig, den er- 
heblichen Anteil an TCP, RTP,. UDP und IP Kontrolldaten in den 
5 verschiedenen headern (320 bit pro Paket bei TCP/IP) der Da- 
tenpakete zu reduzieren. 

Dazu werden die Paketdaten eines PDP zunachst dem PDCP Proto- 
koll (3G TS 25.323, Packet Data Convergence Protocol (PDCP), 

10 3GPP Marz 2000, 

http://www,3gpp,org/ftp/Specs/March_00/25_series/25323- 

310 . zip) 

iibergeben. Dieses Protokoll ist vor der Datenubertragung vom 
RRC Protokoll (3G TS 25.331, Radio Resource Control (RRC) , 

15 3GPP Marz 2000, 

http://www. 3gpp.org/ftp/Specs/March__00/25_series/25331- 
320. zip) 

instanziiert und konfiguriert worden. Es manipuliert nun die 
Paketdaten zweckmafligerweise so, daB sie effizient uber die 

20 UMTS Luftschnittstelle des jeweiligen Teilnehmergerats 

und/oder der jeweiligen Funkkontrolleinheit des UMTS- Funk- 
kommunikat ions systems ubertragen werden konnen. Dazu wird e- 
ventuell eine Kompression der Paketkontrolldaten (header 
compression) zur Datenreduktion und eine Nummerierung der Da- 

2 5 tenpakete zur Datenverlust- und -vervielf achungserkennung 

durchgefuhrt . Je nachdem wie das PDCP Protokoll konfiguriert 
wurde, stellt es den Paketdaten einen PDCP header vorran oder 
nicht, Zusammen mit diesem header (wenn vorhanden) bilden die 
durch PDCP aufbereiteten Paketdaten dann ein PDCP Paket, wel- 

30 ches dem RLC Protokoll tibergeben wird. 

Das RLC Protokoll hat insbesondere die Aufgabe die PDCP Pake- 
te, welche eine GroBe zwischen 0 und 1502 Oktets aufweisen 
konnen, auf Pakete aufzuteilen, deren GroJJe vorzugsweise an 
35 die Obertragung uber die Luftschnittstelle angepaBt ist. Da- 
bei kann es zu einer Segmentierung der Pakete oder zu einem 
Zusammenfiigen mehrerer Pakete zu einem groBeren Paket kommen. 
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Je nach Konf iguration des RLC Protokolls, kann RLC den so 
entstandenen RLC Paketen einen RLC header vorran setzten oder 
nicht. RLC nutzt dann die Dienste der MAC Schicht (3G TS 
25.321, Mediiam Access Control (MAC), 3GPP Marz 2000/ 
5 http://www.3gpp.org/ftp/Specs/March_00/25_series/25321- 

330.zip), urn die RLC Pakete liber die Luf tschnittstelle zu u- 
bertragen. 

Die Protokollarchitektur der UMTS Luf tschnittstelle des je- 
10 weiligen Teilnehmergerats und/oder der jeweiligen Funkkon- 
trolleinheit des UMTS- Funkkommunikationssystems ist insbe- 
sondere in 3G TS 25.301, UMTS Protocol Architecture, 3GPP 
Marz 2000, 

http: //www. 3gpp. org/f tp/Specs/March_00/25_series/25301- 

15 340.zip beschrieben. Grundsatzlich bezeichnet man die Dienst- 
zugangspunkte, an denen die UMTS Luf tschnittstelle den 
Schichten daruber, speziell den Paketdatenprotokollen (PDPs) , 
ihren Dienst zur Verftigung stellt, als Radio Bearer. Dieser 
Begriff bezeichnet also einen Dienst, der die transparente 

2 0 iibertragung von Daten vom Mobilf unkendgerat bzw. Teilnehmer- 
geat (=User Equipment = UE) uber eine oder mehrere Basisista- 
tionen (Node B) zu einer Mobilf unknetzwerkeinheit, insbeson- 
dere Funkkontrolleinheit (Radio Network Controler, RNC) er- 
moglicht. Radio Bearer ist also insbesondere ein Trager- 

25 dienst, urn Daten tiber die Luf tschnittstelle des UMTS- Funk- 
kommunikationssystems zu tibertragen. Es ist moglich, mehrere 
Radio Bearer in einem UE, d.h. Teilnehmergerat , zu nutzen, 
beispielsweise dann, wenn zwei Applikationen ihr Daten mit 
unterschiedlichen Dienstqualitaten tibertragen wollen und dazu 

30 zwei unterschiedliche Radio Bearer aufbauen. Der Aufbau und 

die Konf iguration der Radio Bearer, ebenso wie die Konfigura- 
tion aller beteiligten Protokolle und die Aushandlung der 
Konf igurationsparameter der Luf tschnittstelle wird vorzugs- 
weise von einem ubergeordneten Protokoll wie z.B. RRC (3G TS 

35 25.331, Radio Resource Control (RRC), 3GPP Marz 2000, 

http : //www. 3gpp. org/ftp/Specs/March_00/25_series/25331- 
320 . zip) gesteuert - 
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7 

Im Rahmen der Erfindung ist insbesondere die Funktionsweise 
der PDCP Schicht von UMTS von besonderem Interesse, die hier 
im Detail nachfolgend beschrieben wird. 

5 

In der PDCP-Schicht ist ftir jeden Radio Bearer, der Paketda- 
ten ubertragen soil, zweckmafiigerweise genau eine PDCP Proto- 
kollinstanz vorhanden. Beim Aufbau eines solchen Radio Bea- 
rers wird also eine PDCP Protokollinstanz initiiert und kon- 
10 figuriert. Die moglichen Aufgaben einer solchen PDCP Instanz 
sind beispielsweise : 

- Header Compression (Kontrolldatenreduktion) 

- Datenpaketnummerieriing (zur Erkennung von Paketverlusten 
Oder -duplizierungen in bestimmten Fallen) 

15 - Datenubertragiing (das Weitergeben der ggf . manipulierten 
Daten vom PDP an die RLC-Schicht zum weiteren Transfer) 

- Entsprechende Funktionen in der PDCP Empf angerseite (Hea- 
der Decompression, Ubertragung empfangener Daten von RLC 
and das PDP) 

20 

Zur Header Compression konnen in einer PDCP Instanz insbeson- 
dere null (keine Kompression) , ein oder mehrere verschiedene 
Kompressionsverf ahren mit entsprechenden Algorithmen durch 
ein Oder mehrere entsprechend implementierte Datenkompressi- 

25 onseinheiten benutzt werden. In der augenblicklich gultigen 

Form des UMTS Standards ist nur ein moglicher Algorithmus zur 
TCP/IP header compression nach RFC 2507 spezifiziert (RFC 
2507, IP Header Compression, IETF Februar 1999, 
http: //www. ietf .org/rfc^html) , jedoch wird es in Zukunft al- 

30 ler Voraussicht nach noch mehrere andere Kompressionsverf ah- 
ren in PDCP (z.B. auch flir RTP/UDP/IP header compression) ge- 
ben. Kompressionsverf ahren zur Kontrolldatenreduktion funkti- 
onieren dabei insbesondere in etwa nach folgendem Prinzip: 

35 PDCP Sender und Empfanger legen zur Laufzeit der Datenuber- 

tragung eine identische Datenbank von gespeicherten Kontroll- 
datenkopfen oder Teilen davon an. Diese Datenbank ist am An- 
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fang der Dateniibertragung (also direkt nachdem der Radio Bea- 
rer und damit die PDCP Instanz aufgebaut wurde) leer und wird 
mit der Zeit gefiillt. Jedesmal wenn PDCP im Sender ein Daten- 
paket (bspw. IP Paket) von einer hoheren Schicht bekoinint, 
5 vergleicht die zugeordnete Datenkompressionseinheit deren 

Kontrolldatenkopf (oder Telle davon) mit den in der Datenbank 
gespeicherten Kontrolldatenkopf en* Findet er eine weitgehende 
tfbe reins tiininung, dann ersetzt er den gesamten Kontrolldaten- 
kopf Oder Telle davon durch einen oder mehrere Verweise auf 

10 die Datenbank. Der Dekoiapressionsalgorithmus im Empf anger des 
jeweiligen Teilnehmergerats und/oder der jeweiligen Netzwerk- 
einheit wie z.B. radio network controller kann dann mit die- 
sem Verweis in seiner Datenbank nach den entsprechenden In- 
formationen suchen und mit ihrer Hilfe den ursprunglichen 

15 Kontrolldatenkopf wiederherstellen , Findet die Steuer- 

/Recheneinheit im Sender jedoch keine Ubereinstimmung, dann 
sendet dieser einen Full Header, also einen unveranderten 
Kontrolldatenkopf. Sender und Empf anger tragen diesen in ihre 
Datenbank zur spateren Verwendung ein. Urn dem Empf anger das 

20 Erkennen der Art der empfangenen Kontrolldaten zu ermogli- 

chen, wird den Daten die Information zweckmaBigerweise mitge- 
schickt werden, welcher Art die Kontrolldaten sind. In dem 
hier beschreibenen Prinzip ware das also z.B. die Information 
"Full Header" oder "Verweis auf Datenbank". Diese Information 

25 heiiit in PDCP insbeondere Packet Identifier (PID) . 

Es gibt bei effizienten Kompressionsalgorithmen daruberhinaus 
weitaus mehr Alternativen als nur das Senden eines Full Hea- 
ders Oder eines Verweises. Bei dem im Augenblick verwendeten 
30 Kompressionsverf ahren nach RFC 2507, IP Header Compression, 

IETF Februar 1999, http: //www, ietf.org/rfc.html gibt es ins- 
besondere folgende PIDs: 

Full header. Compressed TCP, Compressed TCP non-delta. Com- 
pressed non-TCP, Context state 

35 

Es gibt vorzugsweise zwei ahnliche, aber im Sinne des PDCP 
Protokolls unterschiedliche Arten, die PID zu versenden: 
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Entweder die jeweilige Datenkompressionseinheit , wie der in 
RFC 2507, IP Header Compression, IETF Februar 1999, 
http://www.ietf.org/rfc.html spezif izierte, tauscht ggf. den 
Kontrolldatenkopf gegen die entsprechenden Daten aus der 
5 Datenbank aus und signalisiert dem PDCP Protokoll, welcher 
Art diese Daten sind. Dann ist das PDCP Protokoll dafur 
zustandig, diese Information (also die PID) an das Empfanger 
PDCP Protokoll zu schicken, damit dieses der jeweiligen De- 
kompressionseinheit die Art der empfangenen Kontrolldaten 

10 signalisieren kann. Oder die jeweilige Datenkompressionsein- 
heit tauscht ggf. den Kontrolldatenkopf gegen die entspre- 
chenden Daten aus der Datenbank und die Signalisierung der 
Art dieser Daten aus. In diesem Fall ist es nicht erforder- 
lich, dalJ das PDCP Protokoll eine weitere Signalisierung an 

15 die Empfangerseite ubermittelt, da die jeweilig zugeordnete 

Dekompressoinseinheit diese Information aus den tibermittelten 
Daten entnehmen kann . 



Urn im PDCP Protokoll den Einsatz beider Verfahren zu ermogli- 
20 chen, wurden flir dieses Protokoll insbesondere mehrere Forma- 
te fur die PDCP Paketdateneinheiten (PDCP Paket Data Units, 
PDU (, das sind die Paketeinheiten die im jeweiligen Sender 
von PDCP an RLC ubergeben und im jeweilig zugeordneten Emp- 
fanger von RLC an PDCP ubergeben werden, ) spezif iziert . 

25 

Dabei enthalt ein erstes, vorteilhaf tes PDCP PDU Format nur 
die von der jeweiligen Datenkompressionseinheit erzeugten Da- 
ten (PDCP-No-Header-PDU) . Diese werden in das Feld "Data" 
eingetragen (siehe Tabelle 4 aus 3G TS 25.323, Packet Data 
30 Convergence Protocol (PDCP) , 3GPP Marz 2000, 

http: / /www. 3gpp .org/ ftp/Specs /March_00/25_ser ies/25323- 
310.zip). Diese ist schematisch wiedergegeben: 

Tabelle 4: PDCP-No-Header PDU 

Data ~ 



BNSDOCID: <WO_ _0a01774A2_l_> 



wo 02/01774 



PCT/DEOl/02327 



10 

Ein anderes vorteilhaf tes PDCP PDU Format enthalt dartiberhi- 
naus noch Inf ormationen uber die FID und ein Feld, das das 
Format dieser PDU von weiteren PDU Formaten unterscheidet 
(siehe Tabelle 5 aus 3G TS. 25.323, Packet Data Convergence 
5 Protocol (PDCP), 3GPP Marz 2000, 

http://www.3gpp.org/ftp/Specs/March 00/25 series/25323" 
310 > zip , die nachfolgend schematisch wiedergegeben ist) . 

Tabelle 5: PDCP-Data-PDU format 

PDU type I PIP 
Data 



10 Beim Aufbau oder der Rekonf iguration eines Radio Bearers wird 
vom RRC Protocol unter anderem ausgehandelt, ob die zu diesem 
Radio Bearer gehorende PDCP Instanz dem Feld Data noch eigene 
Kontrolldaten hinzufiigt oder nicht. Wenn nicht, dann kann 
PDCP nur das in Tabelle 4 gezeigte PDCP PDU Format verschi- 

15 cken. Wenn PDCP den Daten einen eigenen Kontrolldatenkopf 

hinzuftigt, kann es in vorteilhaf ter Weise mehrere alternative 
PDU Formate nutzen, die im Empf anger jeweils durch das Feld 
"PDU type" {immer die ersten 3 bit) unterschieden werden kon- 
nen. 

20 

Werden mehrere verschiedene Datenkompressionsverf ahren fiir 
einen Radio Bearer in einer PDCP genutzt, so ist es insbeson- 
dere die Aufgabe des Sender PDCP Protokolls, fiir jedes Daten- 
paket von einem PDF ein geeignetes Datenkompressionsverf ahren 

25 auszuwahlen und dem Empfanger das verwendete Datenkompressi- 
onsverf ahren zu signalisieren. Das geht insbesondere dann, 
wenn die PDCP Instanzen fiir die Verwendung der PDU Formate 
mit PDCP Kontrolldatenkopf konfiguriert wurden. Das verwende- 
te Datenkompressionsverf ahren wird dann in dem PID Feld 

30 zweckmaiiigerweise wie folgt mitsignalisiert : Die PID Werte, 
die das erste der Datenkompressionsverf ahren benutzt, werden 
den ersten PID Werten zugeordnet. Die PID Werte, die das 
zweite Datenkompressionsverf ahren benutzt, werden fortlaufend 
weiteren PID Werten zugeordnet. Der PID Wert Null ist dabei 

35 immer fiir die Signalisierung eines nicht komprimierten Pakets 
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verwendet, was auch als eine Kompression, namlich als Null- 
Kompression betrachtet warden kann. Sind beispielsweise das 
Datenkompressionsverfahren nach RFC 2507, IP Header Compres- 
sion, IETF Februar 1999, http://www.ietf.org/rfc-html mit den 
5 oben genannten PIDs und ein weiteres Datenkompressionsverfah- 
ren {Method A) mit den PIDs Al, A2 iind A3 fur eine PDCP In- 
stanz vergeben, dann wird das Feld PID in dieser PDCP Instanz 
wie folgt kodiert (nach Tabelle 1 aus 3G TS 25.323, Packet 
Data Convergence Protocol (PDCP), 3GPP Marz 2000, 
10 http : //www, 3 gpp.org/ ftp/Specs/March_0 0/2 5_series/25323- 
310 . zip) ) : 

Tabelle 1: Example of the PID value allocation table 



PID 
Value 


Algorithmus 


Packet type 


0 


No header compression 




1 


RFC2507 


Full header 


2 


RFC2507 


Compressed TCP 


3 


RFC2507 


Compressed TCP nondelta 


4 


RFC2507 


Compressed non TCP 


5 


RFC2507 


Context state 


6 


Method A 


A1 


7 


Method A 


A2 


8 


Method A 


A3 




Unassigned value 





Die PDCP Empf angerinstanz kann nun durch Auslesen des PID 
Wertes sowohl das verwendete Datenkompressionsverfahren als 
15 auch die Art der Kodierung innerhalb eines Datenkompressions- 
verf ahrens ermitteln. 

Eine weitere Funktion des PDCP Protokolls kann die Nuramerie- 
rung von PDCP PDUs sein, wenn dies vom RRC Protokoll so kon- 

2 0 figuriert wurde . Die dann mit jeder PDCP PDU assoziierte Nixm- 
mer wird im Allgemeinen nicht mit der PDCP PDU iiber die Luft- 
schnittstelle gesendet, sondern dient zur Paketverlust- oder 
Paketduplikationserkennung im Falle einer sogenannten SRNS 
(serving radio network subsystem) . Im Zusammenhang mit dieser 

25 Erfindung ist dabei insbesondere nur die Existenz der Numme- 
rierungsfunktion, jedoch nicht die genaue Funktionsweise, re- 
levant. 
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Im General Paket Radio System (GPRS) stellt das SNDCP Proto- 
koll (3G TS 24*065, Subnetwork Dependant Convergence Protocol 
(SNDCP), 3GPP Marz 2000, 

http://www.3gpp-org/ftp/Specs/March_00/24_series/24065- 
310.zip) eine ahnliche Funktionalitat dar, wie das PDCP Pro- 
tokoll in UMTS: Die Anpassung von PDP Datenpaketen an die U- 
bertragung tiber die Luf tschnittstelle . Dazu wird auch in 
SNDCP ein Kontrolldatenkompression, aber auch einige andere 
Funktionalitaten angewendet. Insbesondere ist es in der SNDCP 
Schicht moglich, die Daten von mehreren PDPs (also z.B. von 
verschiedenen IP Protokollen) auf denselben von SNDCP genutz- 
ten Kanal zu multiplexen . Das vorteilhafte Verfahren dazu ist 
im Folgenden beschrieben: 

Ein Network Service Access Point Identifier (NSAPI) wird beim 
Aufbau einer logischen GPRS Datenverbindung (PDP context ac- 
tivation) fur jedes Paketdatenprotokoll (PDP) vergeben, das 
die SNDCP Schicht nutzt. Dieser NSAPI hat einen Wertebereich 
von 0 15 und wird mit jedem versendeten Datenpaket in ei- 
nem Kontrolldatenkopf mitgeschickt . SNDCP auf der Empfanger- 
seite kann mit Hilfe dieses Wertes dann den Nutzer der SNDCP 
Schicht (also das entsprechende PDP) ausmachen und ihm die 
Daten nach dem Demultiplexen und ggf . anderen Datenmanipula- 
tionen ubergeben. 

Um nun einen effizienten Datenaustausch zwischen den Funkti- 
onseinheiten wie z.B. Teilnehmergeraten, Funkkontrolleinhei- 
ten, etc. zu ermoglichen, werden erf indungesgemaB in der je- 
weiligen Sendeeinheit Paketdaten verschiedener Radio Bearer 
innerhalb der PDCP Schicht von UMTS als Tail des PDCP Proto- 
kolls vorzugsweise auf eine Funkkontrolleinheit , insbesondere 
RLC Einheit, gemultiplext . In der jeweilig zugeordneten Emp- 
fangseinheit wird korrespondierend dazu ein entsprechendes 
Demultiplexen der empfangenen Datenpakete vorgenommen. 

Als Sendeeinheit kann vorzugsweise ein Teilnehmergerat , ins- 
besonders Mobil funkgerat, oder ein RNC-Controller (Radio Net- 
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work Controller) verwendet sein. Als Empf angseinheit kann 
vorzugsweise ein Teilnehmergerat, insbesondere Mobilfunkge- 
rat, Oder ein RNC-Controller (Radio Network Controller) ver- 
wendet sein. 

5 

Es wird dazu geitiafi der Erfindung ein Multiplex-Modell vorge- 
stellt, dafi mit moglichst geringen Anderungen am bestehenden 
UMTS- System (wichtig fiir die Akzeptanz im Standardisie- 
rungsprozeiJ) ein moglichst effizientes Multiplexen zulaBt: 

10 

Das Multiplexen erfolgt dabei auf zwei unterschiedliche Ar- 
ten, je nachdem was fiir PDCP PDU Formate fur das PDCP Proto- 
koll konfiguriert wurden: 

15 1. Multiplexen mit Signalisierung : 

In dem Fall, dass fur die PDCP Protokoll Instanz die Verwen- 
dung von PDCP eigenen Protokolldatenkopf en konfiguriert wur- 
de, und dass verschiedene Radio Bearer nicht dengleichen Kom- 
pressionsalgorithmus nutzen, wird das bestehende PID Feld fiir 

20 die zum Multiplexen notige Signalisierung verwendet: 

Es wird jedem Radio Bearer, der die PDCP Protokoll Instanz 
nutzt, mindestens ein PID Wert zugeordnet. Solchen Radio Bea- 
rern, fur die Datenkompressionsverf ahren in PDCP konfiguriert 
25 wurden, die die PID Signalisierung durch PDCP fordern, werden 
nach im Stand der Technik bekannten Verfahren bereits PID 
Werte zugeordnet. 

Radio Bearern, die keine Kompressionsverf ahren nutzen, oder 
fur die Datenkompressionsverf ahren konfiguriert wurden, die 
30 keine PID Signalisierung fordern, werden erf indungsgemafi nun 
dennoch stets PID Werte (genau einer pro Radio Bearer) zuge- 
ordnet . 

Da das PDCP Protokoll so konfiguriert ist, dass es jedem Da- 
tenpaket einen Kontrolldatenkopf voranstellt, der das PID 
35 Feld enthalt, ist somit in vorteilhaf ter Weise die Informati- 
on zum Demultiplexen in jeder PDCP PDU enthalten. Die empfan- 
gende PDCP Instanz liest das PID Feld aus und nutzt es unter 
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anderem, urn den richtigen Empf anger der Daten (das richtige 
PDP) zu bestiinmen. 

•Bei diesem Multiplexverf ahren mit Signalisierung finden die 
konf igurierten Kompressionsverf ahren vor dem Multiplexen An- 
wendung. Dabei sind die verwendeten Kompressionsverf ahren un- 
terschiedlich, weil nur dann die PID Werte neben den verwen- 
deten Datenkoiupressionsverf ahren und ggf . der Kompressionsart 
auch eindeutig einen Radio Bearer (also ein PDP) identifizie- 
ren konnen. 

Dieses Verfahren hat insbesondere den Vorteil, dass die PDCP 
Protokoll Instanz die Daten auch in komprimierter Form oder 
Pakete von verschiedenen PDP Typen eindeutig einem Radio Bea- 
rer zuordnen kann, obwohl sie die PDP Adresse nicht auslesen 
kann, da sie entweder kompriiaiert ist oder das PDCP Protokoll 
keine Kenntnis liber den PDP Typen hat. 

Ein weiterer Vorteil liegt insbesondere darin, dass das im 
Stand der Technik vorhandene PID Feld genutzt wird, urn die 
Multiplex-Inf ormationen zu transportieren und dass zusatzli- 
che Werte aus dem Wertebereich des PID Feldes nur solchen Ra- 
dio Bearern zugeordnet werden, die nach dem Stand der Technik 
keine PID nutzen, 

2. Multiplexing ohne Signalisierung: 

In dem Fall, dass fur die PDCP Protokoll Instanz die Verwen- 
dung der PDCP-No-header-PDU (immer ausschlieJSlich) konfigu- 
riert wurde, oder das mehrere Radio Bearer dasselbe Kompres- 
sionsverf ahren nutzen, wird die PDP Adresse ftir die Vertei- 
lung der Pakete auf verschiedene Radio Bearer verwendet. 

Da in der PDCP PDU kein Feld ftir vom PDCP Protokoll generier- 
te Daten vorhanden ist, oder Radio, Bearer, die das gleiche 
Kompressionsverf ahren nutzen, nicht eindeutig durch das PID 
Feld identifiziert werden konnen, verlaBt sich PDCP vorzugs- 
weise auf die Signalisierung in den PDP eigenen Kontrollda- 
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ten. Es warden also in der PDCP Instanz im Sender den Paket- 
daten keine Kontrolldaten hinzugefugt, so dass im Empfanger 
aus den Paketdaten die PDP-Adresse ausgelesen und fiir das 
Weiterleiten zu dem entsprechenden Radio Bearer genutzt wird. 

5 

Bei diesem Verfahren ist der PDCP Protokoll Instanz die Art 
des PDP (z.B. IP) bekannt. Da diese nicht signalisiert wird, 
konnen bei diesem Verfahren durch ein PDCP Protokoll nur Ra- 
dio Bearer von gleichen PDP gemultiplext werden. Desweiteren 
10 nutzen - wenn header compression genutzt wird - alle Radio 
Bearer zweckmaBigerweise dasselbe Kompressionsverf ahren, da 
eine Unterscheidung zwischen Radio Bearern erst nach der De- 
kompression gemacht werden kann. 

15 Eine weitere Bedingung, die jedoch in UMTS immer erfullt ist, 
ist, dass die Radio Bearer, die zusammen gemultiplext werden 
sollen, eine unterschiedliche PDP-Adresse haben. In UMTS kann 
zwar ein PDP (also eine PDP-Adresse) mehrere Radio Bearer 
nutzen, jedoch unterscheiden diese sich immer in der genutz- 

20 ten Dienstequalitat (QoS) ; da gemultiplexte Radio Bearer 

diegleiche RLC Einheit nutzen, nutzen sie auch dengleichen 
QoS. Deshalb werden Radio Bearer mit gleicher PDP-Adresse^ 
nicht auf dieselbe RLC Einheit gemultiplext, um deren Daten- 
strome spater wieder eindeutig klassif izieren und den radio 

2 5 bearern zuordnen zu konnen. 

Dieses Verfahren hat insbeondere den Vorteil, dali es ohne 
weitere Signalisierung iiber die Luf tschnittstelle das Multip- 
lexen von ( theoretisch) beliebig vielen Radio Bearern auf ei- 
30 nen Datenstrom zulafit. 

Die beiden oben beschriebenen Verfahren werden zweckmafiiger- 
weise jeweils allein oder gemeinsam in PDCP verwendet, abhan- 
gig davon wie die PDCP Protokoll Instanz konfiguriert wurde: 

35 

Wenn das PID Feld in der PDCP PDU vorhanden ist, dann wird es 
vorzugsweise zum Multiplexen fiir solche Radio Bearer genutzt. 
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die eindeutig durch das PID Feld zu identif izieren sind: Das 
sind solche Radio Bearer denen eindeutige PID Werte zugewie- 
sen werden konnen, die also keine Kompressionsverf ahren nut- 
zen, die auch von anderen Radio Bearern genutzt werden, son- 
5 dern deren Datenstrome mit verschiedenen Kompressionsverf ah- 
ren beaufschlagt werden (vgl. Figur 3, linke Halfte, Daten- 
strome DS300, DS310, DS320, DS330) . 

1st das PID Feld nicht vorhanden (well die PDCP-No-header-PDU 
10 konfiguriert wurde) oder nutzen Radio Bearer dengleichen Kom- 
pressionsalgorithmus/ dann wird das Multiplexing zweckmaBi- 
gerweise nach den PDP-Adressen angewendet (vgl. Figur 3 rech- 
te Halfte, Datenstrome DS340, DS350, DS360) . 

15 Figur 1 zeigt ein Mobilfunknetz in dem eine Mobilfunkstation 
MP liber eine erste Funkverbindung FV mit einer Basisstation 
BS verbunden ist, welche wiederum liber eine Festnetzverbin- 
dung MNVl mit einer ersten Netzwerkeinheit FC, im UMTS Stan- 
dard als Radio Network Controler {=RNC) bezeichnet, verbunden 

2 0 ist. Eine weitere Festnetzverbindung MNV2 verbindet den RNC 

dann mit einer hoheren Netzwerkeinheit GPRS, gemaB UMTS Stan- 
dard als Serving GPRS Support Node bezeichnet. Diese kommuni- 
ziert schlieBlich tiber eine waiter Festnetzverbindung MNV3 
mit einer nachst hoheren, insbesondere hochsten Netzwerkein- 

25 heit GW, die im UMTS Standard als Gateway GPRS Support Node 
bezeichnet wird, Im folgenden sind jedoch nur die Mobilfunk- 
station, Basisstation und RNC von Interesse. 

Figur 2 zeigt die Protokollschichten dieser 3 Einheiten MP, 
30 BS, FC. Die Mobilfunkstation MP weist die physikalische 

Schicht (physical layer) PLIOO, die Zugangskontrolleinheit 
MACllO (Mediiam Access Control) , sowie die Funkverbindungskon- 
trolleinheit RLC120 (Radio Link Control) und das Paketdaten- 
konvergenzprotokoll PDCP13 0 (Packet Data Convergence Proto- 
35 col) auf. Uber die Funkverbindung FV ist das Teilnehmergera, 
insbeosndere die Mobilfunkstation MP mit der Basisstation BS 
verbunden, die die physikalische Schicht PL14 0 beinhaltet und 
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uber die Festnetzverbindung MNVl mit der Funkverbindungskon- 
trolleinheit PC, insbesondere radio network controller, ver- 
biinden ist. Diese enthalt ihrerseits eine Zugangskontrollein- 
heit MAC150, eine Funkverbindungskontrolle, insbesondere ra- 
5 dio link control, RLC160 sowie eine Paketdatenkonvergenz- 

schicht PDCP17 0 nach PDCP- Protokoll. Zwischen gleichen, ein- 
ander entsprechenden Protokollen gibt es dabei logische Ver- 
bindungen, insbesondere Komiuunikationskanale LV200, LV210, 
LV220 und LV230. 

10 

Die zu ubertragenden Datenpakete werden in der Mobilf unksta- 
tion MP vorzugsweise von der jeweils hoheren Schicht an die 
unter ihr liegende Schicht weitergegeben und schlielilich uber 
die Funkverbindiing FV an die jeweils zugeordnete Basisstation 

15 wie z.B, BS tibertragen, Diese gibt die Pakete uber die Fest- 
Netzverbindxing MNVl an die Funkkontrolleinheit FC weiter, in 
der die Pakete wiederum von einer Schicht an die nachst hohe- 
re Schicht weitergegeben werden. Auf gleiche Weise durchlau- 
fen auch die von der Funkkontrolleinheit FC zu versendenden 

20 Pakete deren verschiedene Protokolle bzw. Funktionseinheiten 
wie z.B. MAC150, RLC160, PDCP170. 

Figur 3 zeigt nun beispielhaft die aneinandergrenzenden Pa- 
ketdatenkonvergenz- und Funkverbindungskontrollprotokolle, 
25 wie sie beispielsweise im Mobil funkgerat MP und in der Funk- 
kontrolleinheit FC der Basisstation BS der Aufenthalts- 
Funkzelle des Mobilf unkgerats vorhanden sind- 

Beim Aufbau eines Radio Bearers werden die RLC und PDCP Pro- 
3 0 tdkolle in der Mobilf unkstation MP und in der Funkkontroll- 
einheit FC vorzugsweise identisch konf iguriert . Beim Aufbau 
des ersten Radio Bearers RB300 wird ftir die Datenpakete des- 
sen Datenstroms DS300 beispielsweise ein Datenkompressions- 
verfahren in einer Datenkompressionseinheit CA400 verwendet, 
35 das vorzugsweise dem in RFC 2507 (request for coinments, Stan- 
darddokioment) , IP Header Compression, IETF Februar 1999, 
http: //www. ietf-org/rf c- html beschriebenen Kompressionsver- 
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fahren entspricht. Nach RFC 2507 sorgt die Datenverbindungs- 
schicht, in diesem Fall also das PDCP Protokoll 130 in vor- 
teilhafter Weise dafur, dali insbesondere zwischen folgenden 
Pakettypen untersciiieden warden kann: ^ 
5 Full header. Compressed TCP, Compressed TCP nondelta. Com- 
pressed non TCP, Context state. Uncompressed TCP/IP, Com- 
pressed TCP/IP 

Somit wird zweckmaBigerweise der in Tabelle 5 aus 3G TS 
10 25.323, Packet Data Convergence Protocol (PDCP), 3GPP Marz 

2 000, http: //www. 3gpp, org/ ftp/Specs /Mar ch__0 0/2 5_series/2532 3- 
310.zip dargestellte PDCP-Data-PDU Paketdaten-Type verwendet. 
Dabei werden den Pakettypen der Datenstrome DS3 00 des radio 
bearers RB300 die PID Werte 1 Bis 7 (1 = Full Header, 2 = 

15 Compressed TCP, , 7 = Compressed TCP/IP) als individua- 

lisierende Kennzeichen zugewiesen. Weiterhin wird fur diesen 
Radio Bearer RB300 in vorteilhaf ter Weise festgelegt, daii er 
den RLC Zugangspunkt (SAP = Service Access Point) SAP500 ver- 
wenden soil, der in der Figur 3 als Ellipse dargestellt ist 

2 0 und den Zugang zu der RLC-Einheit RLC600 darstellt (RLC = ra- 

dio link control) . 

In Datenf luiirichtung vom radio bearer RS300 zur RLC-Einheit 
RLC600 betrachtet werden ausgehend vom radio bearer RB300 die 
25 Datenpakete dessen Datenstroms DS300 in der nachf olgenden Da- 
tenkompressionseinheit CA400 zunachst einem spezifisch zuge- 
ordneten Datenkompressionsverf ahren unterworfen. Zugleich o- 
der anschlieiiend wird fiir diesen komprimierten Datenstrom 
DS400* eine spezifische Kennzeichnung in einer nachf olgenden 

3 0 Kennzeichnungseinheit KE4 00 vorgenommen. Erst danach wird der 

derart individualisierte Datenstrom DS400* einer nachgeordne- 
ten Multiplexereinheit MUPl zugefuhrt. Mit deren Hilfe wird 
der komprimierte und gekennzeichnete Datenstrom des radio 
bearers RB30 0 zusammen mit den Datenpaketen anderer Daten- 
35 strome weiterer radio bearers wie z.B. RB310, RB320, RB330 
gemultiplext der RLC-Einheit RLC600 ubermittelt. 
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Der zweite Radio Bearer RB310 verwendet zweckmaBigerweise e- 
benfalls den RLC SAP500. Die Kompriiaierung der Protokollkon- 
trolldaten der Datenpakete seines Datenstroms DS310 wird je- 
doch mit einem Datenkompressionsverf ahren in einer Datenkom- 
5 pressionseinheit CA410 durchgef uhrt . Fur die Datenpakete die- 
ses Datenstroms DS310 wird hier im Ausfuhrungsbeispiel ange- 
nommen, daJ5 keine Signalisierung durch die Funkverbindiings- 
schicht zur Unterscheidiing der Datenpakete notwendig ist. 
Dennoch wird nach dem Datenkompressionsverf ahren einer Daten- 
10 kompressionseinheit CA410 mit Hilfge einer Kennzeichnungeine- 
heit KE410 dem Datenstrom aus der Kompressionseineheit CA410 
ein bestimmter PID Wert wie z.B. 8 in eindeutiger Weise zuge- 
wiesen. 

15 Ein dritter, anschlieBend' aufgebauter Radio Bearer RB320 ver- 
wendet ebenfalls wie der Datenstrom DS310 des radio bearers 
RB310 das Datenkompressionsverf ahren der Datenkompressions- 
einheit CA410 sowie den RLC SAP500. Da das Kompressionsver- 
fahren der Datenkompressionseinheit DS410 beim Aufbau des Ra- 

20 dio Bearers RB320 bereits existiert, wird kein weiterer PID 
Wert vergeben, sondern derselbe wie fur den Datenstrom DS310 
verwendet. Mit anderen Worten heiBt das, dali die beiden Da- 
tenstrome DS310 und DS320 der beiden radio bearer RB310 und 
RB320 jeweils mit demselben Datenkompressionsverf ahren in der 

25 Datenkompressionseinheit CA410 beaufschlagt werden. Anschlie- 
IJend wird fur den, aus der Kompressionseinheit CA410 kommen- 
den Datenstrom DS410* in einer nachgeordneten Kennzeichnungs- 
einheit eine spezifische Kennzeichnung vorgenommen. Erst dann 
wird dieser individualisierte Datenstrom auf den Multiplexer 

30 MUPl gegeben, um ihn effizient an die RLC-Einheit RLC600 zu 
schicken. 

Fiir einen vierten Radio Bearer RB330 wird angenommen, daB die 
Protokollkontrolldaten nicht komprimiert werden sollen, er 
35 jedoch auch RLC SAP500 verwenden soil. Erf indungsgemaJJ wird 
dem Radio Bearer daher ein weiterer, bestimmter PID Wert wie 
z.B, 9 als individualisierende Kennzeichnung zugewiesen, der 
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vom PID- Wert der anderen Datenkomprimierungseinheiten CA4 00, 
CA410 verschieden ist* Auf Mobilf unkstations- und Funkkon- 
trolleinheitsseite findet dabei die Zuweisung zweckmaBiger- 
weise identisch statt. 

5 

Auf diese Weise warden dem Multiplexer MUPl Datenstrome zuge- 
fuhrt, die mit unterschiedlichen, d.h. voneinander verschie- 
denen Kompressionsverf ahren beaufschlagt sind. Erst nachdem 
sie mit einem Kennzeichen wie z.B. einem unterscheidbaren 

10 PID-Wert individualisiert , d.h. unterscheidbar gemacht worden 
sind, warden sie einem nachf olgenden Multiplexverf ahren zur 
Datenzufuhr an eine RLC-Einheit unterworfen. Unter Kompressi- 
onsverfahren wird dabei auch eine Null- Kompression verstan- 
den. Der nichtkomprimierte Datenstrom wird dabei ebenfalls 

15 mit einer invidualisierenden Kennzeichnung versehen. Allge- 
mein ausgedriickt wird also unabhangig davon, ob das jeweilig 
verwendete Datenkompressionsverf ahren einen PID-Kennzeichner 
verlangt oder nicht, bei Datanstromen^ die geinischten Kom- 
pressionsverf ahren unterworfen warden, stets ein Kennzeichner 

2 0 an den jeweiligen Datenstrom vergeben, bevor dieser nach sei- 
ner Komprimierung an den Multiplexer MUPl ubergeben wird. 

Im folgenden wird nun im einzelnen die Paketdateniibertragung 
von der Mobilfunkstation MP an die Funkkontrolleinheit FC be- 

25 schrieben. Dafur stellt Figur 3 zunachst die RLC und PDCP 

Protokolle 120, 130 in der jeweiligen Sendeeinheit einer Mo- 
bilfunkstation Oder sonstigen Netwerkeineheit, insbesondere 
Funkkontrolleinheit dar. Werden von hoheren Schichten Daten- 
pakete liber den ersten Radio Bearer RB300 an das PDCP Proto- 

30 koll weitergegeben, werden die Paketkontrolldaten gemafi RFC 
2507 mit Hilfe der Kompressionseinheit CA 400 komprimiert. 
Das komprimierte Paket DS400* wird in das Feld "Data" des in 
Tabelle 5 aus 3G TS 25,323, Packet Data Convergence Protocol 
(PDCP), 3GPP Marz 2000, 

35 http: //www. 3gpp.org/ftp/Specs/March_00/25_series/25323- 
310.zip dargestellten PDCP-Data-PDU Pakets eingefiigt. Das 
PDCP Protokoll setzt dann das PID Feld z.B. auf einen Wert 
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zwischen 1 bis 7, je nachdem welche Art von komprimierten Pa- 
ket in das Feld "Data" eingefiigt wurde. Dadurch ist eine in- 
dividualisierende Kennzeichnung des komprimierten Datenstroms 
DS400* bereitgestellt . Dies ist in der Figur 3 dadurch ange- 
5 deutet, dalJ nach der Kompressionseinheit CA 400 und vor der 
Multiplexereinheit MUPl die Kennzeichnungseinheit KE400 ein- 
gefiigt ist. Diese vergibt an die Datenpakete des komprimier- 
ten Datenstroms DS400*, der von der Kompressionseinheit CA400 
zur Multiplexereinheit MUPl weitergeschickt wird, jeweils ein 

10 individuelles Kennzeichen wie z.B- einen PID- Codewert . Wird 
von hoheren Schichten ein Datenpaket liber den zweiten oder 
dritten Radio Bearer RB310, RB320 an das PDCP Protokoll wei- 
tergeben, setzt PDCP das PID-Feld z.B. auf denselben Wert 8. 
Um dieses individualisierende Kennzeichen den Datenpaketen 

15 des aus der Komprimierungseinheit CA410 kommenden Datenstroms 
DS410* anhangen zu konnen, ist der Komprimierungseinheit 
CA410 unmittelbar die Kennzeichnungseinheit KE410 nachgeord- 
net. Erst danach wird dieser gekennzeichnete Datenstrom 
DS410* der Multiplexereinheit MUPl ebenfalls zugefuhrt. Die 

20 Kennzeichnungseinheit CA410 ist also zwischen der Komprimie- 
rungseinheit CA4 00 und der Multiplexereinheit MUPl angeord- 
net. Gelangt das Paket tiber den vierten Radio Bearer RB330 an 
PDCP, wird das PID Feld z.B, auf 9 gesetzt. Diese individua- 
lisierende Kennzeichnung wird dabei zweckmaJiigerweise mit 

25 Hilfe der eigens zugeordneten Kennzeichnungseinheit KE330 

vorgenommen. Erst anschlieiiend wird dieser individualisierte 
Datenstrom DS 3 30* der gemeinsamen Multiplexereinheit MUPl zu- 
gefuhrt. Diese schickt die Datenpakete des Datenstroms DS330* 
liber den RLC Zugangspunkt SAP500 an die RLC-Einheit RLC600 

30 weiter, welche das Paket weiterverarbeitet und schlieJJlich an 
das unter RLC liegende Zugangskontrollprotokoll MAC iiber ei- 
nen sogenannte logischen Kanal LOC700 weiterleitet • MAC gibt 
das Paket wiederum^ an die physikalische Schicht weiter und 
schlieBlich wird das Paket liber die Funkverbindung FV an die 

35 Basisstation BS gesendet^ welche das Datenpaket an die Funk- 
kontrolleinheit FC weitergibt. 
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Im Empf angsbetrieb erfolgt die Verarbeitung der empfangenen 
Datenpakete in umgekehrter Weise beispielsweise f olgenderma- 
Ben: In Figur 3 sind dazu die RLC und PDCP Protokolle 150, 
17 0 in der jeweiligen Empf angseinheit eines Mobilfunkgerats 
5 Oder einer Funkkontrolleinheit dargestellt. Das jeweilig emp- 
fangene Datenpaket wird z.B, in der Funkkontrolleinheit FC 
liber den logischen Kanal LOC700 an die RLC-Einheit RLC600 ti- 
bergeben, welche das Paket uber den RLC SAP500 an das PDCP 
Protokoll weiterleitet . Das PDCP Protokoll kennt in vorteil- 

10 hafter Weise die Moglichkeiten, wie das Paket weitergeleitet 
werden kann, Um das Paket nun korrekt weiterzuleiten, wird 
z we ckmaiSiger weise das PID-Feld ausgewertet. Hat das PID-Feld 
z.B. einen Wert zwischen 1 und 7, wird das Paket an die Kom- 
pressionseinheit CA4 00 weitergegeben, wo das Paket dekompri- 

15 miert und anschlieBend an Radio Bearer 300 weitergeleitet 

wird. 1st der Wert des PID-Feldes gleich 8 wird das Paket an 
die Kompressionseinheit CA410 weitergeleitet und dort de- 
komprimiert . Nach der Dekompression wird die Paketdatenproto- 
koll- (PDP-) Adresse ausgewertet und an Hand dieser Auswer- 

20 tung das Paket entweder an Radio Bearer RB310 oder RB320 wei- 
tergegeben. 1st der Wert des PID-Feldes 9 wird das Paket di- 
rekt an den Radio Bearer RB330 weitergegeben, 

Im Fall, daiJ das PID-Feld beim Datenstrom des jeweiligen ra- 
25 dio bearers nicht vorhanden ist (,weil z.B. die PCDP-No- 

Header-PDU konfiguriert wurde) oder eine Gruppe von mehreren 
radio bearern das gleiche Kompressionsverf ahren nutzt, jedoch 
die verschiedenen Datenstrome aufgrund unterschiedlicher PDF 
Adressen unterscheidbar sind, wird zweckmaliigerweise folgen- 
30 dermalien vorgegangen (vgl. dazu rechten Strang von Figur 3): 

Da in der PDCP PDU kein Feld flir vom PDCP Protokoll generier- 
te Daten vorhanden ist, oder Radio Bearer, die dengleichen 
Kompressionsalgorithmus nutzen, nicht eindeutig durch das FID 
35 Feld identif iziert werden konnen, wird zur individualisieren- 
den Kennzeichnung der Datenstrome wie z.B. DS340, DS350, 
DS360 mehrerer radio bearer wie z.B. RB340, RB350, RB360 in 
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Figur 3 in PDCP vorzugsweise die Signalisierung in den PDP 
eigenen Kontrolldaten herangezogen . Es werden also in der 
PDCP Instanz im Sender den Paketdaten keine Kontrolldaten ei- 
gens, d.h. extra hinzugefiigt, so dass im Empfanger aus den 
5 Paketdaten lediglich die bereits sowieso vorhandene PDP- 

Adresse ausgelesen und fUr das Weiterleiten zu dem entspre- 
chenden Radio Bearer genutzt wird. 

In der Figur 3 werden deshalb die Datenstrome, die inharent 
10 durch jeweils eine unterscheidbare PDP-Adresse gekennzeichnet 
sind und dadurch voneinander unterscheidbar gemacht sind, auf 
einen geme ins amen Multiplexer MUP2 gegeben^ Die individuali- 
sierende Kennzeichnung jedes Datenstroms liegt also bereit 
vor dem Multiplexer MUP2 vor. Dies ist in der Figur 3 durch 
15 den verschiedenen Datenstromen zugehorige Kennzeichnungsmit- 
tel KE340, KE350, KE360 angedeutet. 

Beim Aufbau z.B. des Radio Bearers RB340 wird festgelegt, dafi 
die Protokollkontrolldaten, die von hoheren Schichten an das 

20 PDCP Protokoll weitergegeben werden, mit dem Kompressionsver- 
fahren der nachgeordneten Kompressionseinheit CA420 kompri- 
miert werden sollen. Auiierdem soil der Radio Bearer RB34 0 den 
RLC SAP510 verwenden. Fur dieses Ausftihrungsbeispiel wird 
welter angenommen, daB das Kompressionsverf ahren der Kompres- 

25 sionseinheit CA420 keine Signalisierung durch die Datenver- 

bindungsschicht, also PDCP, erfordert, weshalb keine Paketun- 
terscheidung durch PDCP erfolgen muli, somit auch kein PID- 
Wert als Extrakennzeichnung vergeben . werden muJi und vorzugs- 
weise der in Tabelle 4 aus 3G TS 25.323, Packet Data Conver- 

30 gence Protocol (PDCP), 3GPP Marz 2000, 

http://www.3gpp.org/ftp/Specs/March_00/25_series/25323- 
310. zip dargestellte PDCP-No-Header-PDU Paket-Type verwendet 
werden kann. Die Datenstrome DS350 und DS3 60 der Radio Bearer 
RB350 und RB360 werden ebenfalls der Kompressionseinheit 

35 CA420 zugeftihrt und somit demselben Komprimierungsverf ahren 

unterworfen. Die derart komprimierten Datenstrome werden dann 
gemeinsam liber den RLC SAP510 an die RLC-Einheit RLC610 wei- 
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tergeschickt. Da das Multiplexen auf den RLC SAP510 und somit 
auf die RLC-Einheit RLC610 vorzugsweise ausschlieBlich vor 
der Kompression mit Hilfe der Multiplexereinheit MUP2 statt- 
findet, wird weiterhin in vorteilhaf ter Weise kein PID Wert 
5 benotigt und es wird weiterhin der PDCP-No-Header-PDU Paket- 
Type verwendet. 

Im folgenden wird nun die Paketubertragung von der Mobilfunk- 
station zur Funkkontrollschicht im einzelnen beispielhaft er- 

10 lautert: Zunachst soil Figur 3 daher wieder die RLC und PDCP 
Protokolle 120, 130 in der Mobilfunkstation darstellen. Wird 
nun ein Paket von hoheren Schichten uber einen der Radio Bae- 
rer 340, 350 oder 360 an das PDCP Protokoll gegeben, wird das 
Paket komprimiert und das komprimierte Paket in das Feld "Da- 

15 ta" des in Tabelle 4 dargestellten "PDCP-No-Header-PDU" Pa- 
kets eingefugt und anschlieBend iiber den RLC SAP510 an die 
RLC-Einheit RLC610 weitergegeben. Diese bearbeitet das Paket 
evtl. weiter und gibt es schliefllich liber den logischen Kanal 
LOC710 an das MAC Protokoll weiter, welches das jeweilige Da- 

20 tenpaket ihrerseits an die physikalische Schicht weiterlei- 
tet; von dieser wird letztendlich das jeweilige Datenpaket 
uber die Funkverbindung an die Basisstation gesendet, welche 
das Datenpaket an die Funkkontrolleinheit FC weiterleitet . 

25 Im folgenden wird nun die Paketubertragung in umgekehrter 

Richtung, d.h. von der Funkkontrollschicht zur Mobilfunksta- 
tion naher erlautert: Figur 3 soil dazu nun die RLC und PDCP 
Protokolle 160, 170 der Funkkontrolleinheit darstellen. Das 
jeweilige Datenpaket wird in der Funkkontrolleinheit von un- 

30 ten nach oben durch die Schichten gegeben und gelangt 

schlieiilich uber den logischen Kanal LOC710 zur RLC-Einheit 
RLC610, welche. das Paket uber den RLC SAP510 an PDCP weiter- 
gibt. Das PDCP Protokoll gibt alle Pakete, die von dem RLC 
SAP5/10 kommen an die Kompressionseinheit CA420, die jetzt ei- 

35 ne Dekomprimierung vornimmt. Nach der Dekompression wird dann 
wieder die PDP Adresse ausgewertet, ura das jeweilige Paket an 
den korrekten, zugeordneten Radio Bearer weiterzugeben. 
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Allgemein ausgedrtickt wird also bei eineia ersten erfindunges- 
gemaBen Verfahren zum Multiplexen einer Vielzahl von Datenpa- 
keten mehrerer Datenstrome (DS300, DS310, DS320, DS330) auf 
5 eine zugeordnete Netzwerkeinheit {RLC600) innerhalb des PDCP- 
Protokolls (packet data convergence protocol) mindestens ei- 
ner Sendeeinheit eines UMTS-Funkkommunikationsystems die ver- 
schiedenen Datenstrome (DS300, DS310, DS320, DS330) vor ihrem 
Multiplexen mittels einer Multiplexereinheit (MUPl) rait un- 

10 terschiedlichen Datenkompressionsverf ahren verschiedener Da- 
tenkompressionseinheiten (CA400, CA410) beauf schlagt . Dabei 
wird zwischen der jeweiligen Datenkompressionseinheit (CA400, 
CA410) und der Multiplexereinheit (MUPl) jeweils mindestens 
eine individuelle Kennzeichnung des jeweilig in die Multiple- 

15 xereinheit (MUPl) einlaufenden Datenstroms (DS400*, DS410*, 
DS330) mittels einer zugeordneten Kennzeichnungseinheit 
(KE400, KE410, KE330) vorgenommen, so daJb die in mindestens 
einer Empf angseinheit des PDCP-Protokolls empfangenen Daten- 
pakete eindeutig den ursprtinglich eingespeisten Datenstromen 

20 (DS300, DS310, DS320, DS330) der Sendeeinheit zuordenbar 
sind. 

Nach einem zweiten erf indungsgemaBen Verfahren zum Multiple- 
xen einer Vielzahl von Datenpaketen mehrerer Datenstrome 

25 (DS340, DS350, DS360) auf eine zugeordnete Netzwerkeinheit 
(RLC610) innerhalb des PDCP-Protokolls (packet data conver- 
gence protocol) mindestens einer Sendeeinheit eines UMTS- 
Funkkommunikationsystems werden die verschiedenen Datenstrome 
(DS340, DS350, DS360) nach ihrem Multiplexen mittels einer 

30 Multiplexereinheit (MUP2) in einer gemeinsamen Datenkompres- 
sionseinheit (CA420) mit demselben Datenkompressionsverf ahren 
beauf schlagt . Dabei wird vor der Multiplexereinheit (MUP2) 
jeweils mindestens eine individuelle Kennzeichnung des jewei- 
lig in die Multiplexereinheit {MUP2) einlaufenden Datenstroms 

35 (DS340, DS350, DS360) mittels einer zugeordneten Kennzeich- 
nungseinheit (KE340, KE350, KE360) vorgenommen, so daB die in 
mindestens einer Empf angseinheit des PDCP-Protokolls empfan- 
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genen Datenpakete eindeutig den ursprtinglich eingespeisten 
Datenstromen (DS340, DS350, DS360) der Sendeeinheit zuorden- 
bar sind. Die invidualisierende Kennzeichnung des jeweiligen 
Datenstroms vor der Multiplexereinheit kann dabei bereits in- 
5 harent durch dessen PDP-Feld vordefiniert sein. 

Als Sendeeinheit kann dabei vorzugsweise ein Teilnehmergerat, 
insbesonders Mobilf unkgerat (MP) , oder ein RNC-Controller 
(Radio Network Controller) verwendet werden. Als Empf angsein- 
10 heit kann ebenfalls vorzugsweise ein Teilnehitiergerat , insbe- 
sondere Mobilf unkgerat (MP) , oder ein FUSIC-Controller (Radio 
Network Controller) verwendet sein. Als Netzwerkeinheit wird 
vorzugsweise eine Funkkontrolleinheit (FC) , insbesondere RLC- 
Einheit (radio link control), gewahlt. 

15 
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Patent ansprtiche 

l.Verfahren zum Multiplexen einer Vielzahl von Datenpaketen 
5 mehrerer Datenstrome (DS300, DS310, DS320, DS330) auf eine 
zugeordnete Netzwerkeinheit (RLC600) innerhalb des PDCP- 
Protokolls (packet data convergence protocol) mindestens ei- 
ner Sendeeinheit eines UMTS-Funkkommunikationsystems, wobei 
die verschiedenen Datenstrome (DS300, DS310, DS320, DS330) 

10 vor ihrem Multiplexen mittels einer Multiplexereinheit (MUPl) 
mit unterschiedlichen Datenkompressionsverf ahren verschiede- 
ner Datenkompressionseinheiten (CA400, CA410) beaufschlagt 
werden, und wobei zwischen der jeweiligen Datenkompressions- 
einheit (CA400, CA410) und der Multiplexereinheit (MUPl) je- 

15 weils mindestens eine individuelle Kennzeichnung des jeweilig 
in die Multiplexereinheit (MUPl) einlaufenden Datenstroms 
(DS400*, DS410*, DS330) mittels einer zugeordneten Kennzeich- 
nungseinheit (KE400, KE410, KE330) vorgenommen wird, so daB 
die in mindestens einer Empf angseinheit des PDCP-Protokolls 

20 empfangenen Datenpakete eindeutig den ursprtinglich einge- 

speisten Datenstromen (DS300, DS310, DS320, DS330) der Sende- 
einheit zuordenbar sind. 

25 2. Verf ahren nach Anspruch 1, 

dadurch gekennzeichnet, 

dafi als Sendeeinheit ein Teilnehmergerat ^ insbesonders Mobil- 
funkgerat (MP) , oder ein RNC-Controller (Radio Network Cont- 
roller) verwendet wird. 

30 

3. Verf ahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

dafi als Empf angseinheit ein Teilnehmergerat, insbesondere Mo- 
35 bilfunkgerat (MP) , oder ein RNC-Controller (Radio Network 
Controller) verwendet wird* 
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4, Verfahren nach einem der vorhergehenden Ansprtiche, 
dadurch gekennzeichnet, 

daJJ als Netzwerkeinheit eine Funkkontrolleinheit (FC) , insbe- 
5 sondere RLC-Einheit (radio link control), verwendet wird. 

5, Verfahren ziom Multiplexen einer Vielzahl von Datenpaketen 
mehrerer Datenstrome (DS34 0, DS350, DS3 60) auf eine zugeord- 

10 nete Netzwerkeinheit (RLC610) innerhalb des PDCP-Protokolls 

(packet data convergence protocol) mindestens einer Sendeein- 
heit eines UMTS-Funkkommunikationsys terns, wobei die verschie- 
denen Datenstrome (DS340, DS350, DS360) nach ihrem Multiple- 
xen mittels einer Multiplexereinheit (MUP2) in einer geinein- 

15 samen Datenkompressionseinheit (CA420) mit demselben Daten- 
kompressionsverf ahren beaufschlagt werden, und wobei vor der 
Multiplexereinheit (MUP2) jeweils mindestens eine individuel- 
le Kennzeichnung des jeweilig in die Multiplexereinheit 
(MUP2) einlaufenden Datenstroms (DS340, DS350, DS360) mittels 

20 einer zugeordneten Kennzeichnungseinheit (KE340, KE350, 

KE360) vorgenommen wird, so daB die in mindestens einer Emp- 
fangseinheit des PDCP-Protokolls empfangenen Datenpakete ein- 
deutig den ursprtinglich eingespeisten Datenstromen (DS340, 
DS350, DS360) der Sendeeinheit zuordenbar sind. 

25 

6, UMTS- Funkkommunikationssystem, in dem der Austausch von 
Datenstromen zwischen dessen Teilnehmergeraten, insbesondere 
Mobilfunkgeraten (MP), und Netzwerkeinheiten, insbesondere 

30 Funkkontrolleinheiten (FC) , nach einem der vorhergehenden An- 
spriiche vorgenommen wird. 
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